feat(reports): allow API requests to filter rules to evaluate #977
Conversation
* test(graphql): add basic targetNodes query itest * test(graphql): add targetNodes test with filter * test(graphql): add more itests Add tests for starting recording and querying environmentNodes * test(graphql): add archive/delete itests * remove println
* build(oci): transform image tag to lower case * Update CI as well
|
Approach 2 sounds good to me. No need to have overloaded versions for with- and without-filters - just let the filter String be nullable, or
Ah right, makes sense. I should have thought ahead to that point when reviewing your It's OK to add the util function and have it as essentially duplicate code across the repos for now. Later on we can extract that logic out into a util in |
|
Feedback please :) requests with filters are added with a query string ?filter="[filter1],[filter2],..." on the ReportGetHandler and TargetReportGetHandler Here is a small messy rundown of what happens with each type filter query when no filter (Attribute is not given) when filter="[badfilter, badfilter2]" |
src/main/java/io/cryostat/net/reports/ArchivedRecordingReportCache.java
Outdated
Show resolved
Hide resolved
src/main/java/io/cryostat/net/reports/ActiveRecordingReportCache.java
Outdated
Show resolved
Hide resolved
src/main/java/io/cryostat/net/reports/RemoteReportGenerator.java
Outdated
Show resolved
Hide resolved
src/main/java/io/cryostat/net/web/http/api/v1/ReportGetHandler.java
Outdated
Show resolved
Hide resolved
… uncached, updated tests with changes
|
I will remove prints once OK'd. |
Resolves #918
Right now, I am wondering how I should have the optional
String filterbe used in the API, because there are a lot of methods and steps to go through receiving the request from the client, to going through execs, to finally sending a post request.I have two options right now as to how I should structure the optional
filterstring.Should we overload all the methods such that we are able to specify an optional
filterString as a parameter? The benefits of this I see are that it's easy to see if we are including "filters" in a request since a argument wouldn't be supplied, but the drawback is that it's doubling the methods that are needed to go through the process.The second option is what I am doing right now in the code, where I am supplying a
filterString parameter for all the methods that need it and I only check at the very end, (in this case:execinRemoteReportGenerator) if the String is empty or not. If the string was empty, then we just send a POST request normally without the query string, if it wasn't etc. etc....An unrelated question, but in
SubprocessReportGeneratorthe class directly uses [cryostat-reports]'s InterruptibleReportGenerator method inReportResource.javawhich I updated in the last pr. And in that class, I use I made my own predicate combiner thing, and I also use it inSubprocessReportGeneratorby making a new util function. Is this the right approach so that I will eventually refactor the [cryostat-reports] class to use the util function as well?Thanks!